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Abstract 


This document describes an RTP [1] payload format for transporting 
the coordinates of a dynamic pointer that may be used during a 
presentation. Although a mouse can be used as the pointer, this 
payload format is not intended and may not have all functionalities 
needed to implement a general mouse event transmission mechanism. 


1. Introduction 


In most presentations, significant information is conveyed through 
the use of viewgraphs and a pointer. This makes accurate transmission 
of them vital in remote conferencing applications. Using regular 
video of a presenter’s display for this purpose is problematic 
because, while the viewgraphs require a high spatial resolution, the 
pointer movements need to be sampled and transmitted at a high 
temporal resolution so that the presenter’s pointing actions can be 
displayed synchronously with the corresponding audio and video 
signals. In many instances, this synchronization carries vital 
information. As an example, consider a speaker pointing at two 
alternatives on a viewgraph in sequence and saying "this one is 
better than this". To satisfy both high spatial and high temporal 
resolution requirements, at least S-VHS quality video may need to be 
used. Codecs that can compress S-VHS video effectively in real-time 
are expensive for this purpose, and transmitting such video 
uncompressed requires very high bandwidths. 
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A much simpler and economical system can be designed by capturing and 
transmitting the pointer coordinates separately [2]. The pointer 
coordinates with respect to a displayed viewgraph can easily be 
obtained in electronic presentation systems. For presentations 
prepared for optical systems, such as transparencies for overhead 
projectors, an arrangement where the viewgraph is captured in a frame 
buffer on a computer can be used to associate the pointer coordinates 
with the displayed viewgraph. For capturing transparencies, printed 
material, or even three dimensional objects, a document camera and a 
personal computer or workstation based video capture card can be 
used. This arrangement can handle electronic viewgraphs by feeding 
the video output of the computer that displays them to the video 
capture card through an appropriate converter also. A side benefit of 
this is that it allows using a presenter’s own computer to transmit 
electronic viewgraphs without connecting it to, for example, an 
intranet. The captured image is then displayed along with the 
capturing computer’s mouse pointer on the presenter’s display using a 
projector. The presenter moves the pointer on the display using a 
regular or maybe a wireless mouse whose location can easily be 
captured by appropriate software running on the capturing computer. 


This document describes an RTP payload format to transmit the pointer 
coordinates captured in one of the ways described above using RTP. 
Although, a mouse can be used as the pointer, this payload format is 
not intended and may not have all functionalities needed to implement 
a general mouse event transmission mechanism. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [3]. 
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2. Payload Format 


0 1 2 3 

0 1:2:3-4 506 18-90 13203 4-56 738 9-0 1:2: 3-4 :5: 6 7-89 0 1 
Hm de me pt 
|v=2|P|x| cc |m] PT | sequence number 

He mm de me pt 
| timestamp | 
+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
synchronization source (SSRC) identifier | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
contributing source (CSRC) identifiers : 
+=+=+=+=+=t+=+=+=t+=t+=+=t=t=t=t=t=t=t=t=t=t=t=t=t=t=t+=t+=+ 


+=+=+=+=+ 

|[L[M[R] | x-coordinate | | PIN | y-coordinate 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
MBZ MBZ 


Figure 1 - An RTP packet for Real-Time Pointer 


Fig. 1 shows an RTP packet carrying real-time pointer coordinates. 
This payload format does not have a payload specific header. 


2.1. RTP Header Usage: 
Payload Type (PT): The assignment of an RTP payload type for this new 
packet format is outside the scope of this document, and will not be 
specified here. It is expected that the RTP profile for a particular 
class of applications will assign a payload type for this encoding, 
or if that is not done then a payload type in the dynamic range shall 
be chosen. 


Marker (M) bit: Set to one if the pointer icon is changed in this 
packet. 


Extension (X) bit: Defined by the RTP profile used. 
Sequence Number: Set as described in RFC1889 [1]. 


Timestamp: The sampling time for the pointer location measured by a 
90kHz clock. 


SSRC: Set as described in RFC1889 [1]. 
CC and CSRC fields are used as described in RFC 1889 [1]. 


RTCP SHOULD be used as defined in RFC 1889 [1]. 
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2.2. Payload: 
The pointer’s x and y coordinates are measured from the upper left 
corner of the associated display window. They are represented as a 
fraction of the corresponding edge length of the display window using 
12 bits, positive, fixed point numbers between 0 and (1 - 2%-12). 
L (left), R (right) and/or M (middle) bits are pointer special 
effects flags. Their use is application dependent and MUST be 
established out-of-band. Applications MAY ignore these bits. 
PIN: Pointer Icon Number (3 bits) selects a pointer icon. The 
association between the PIN numbers and the icon pictures MUST be 
established out-of-band. PIN = 0 represents a default pointer icon. 
Applications which only support a single pointer icon SHOULD set the 
PIN field to zero. Applications MAY ignore non-zero PIN values on 
reception, and display a default icon. 

3. MIME Media Type Registrations 


This document defines a new RTP payload name, "pointer," and 
associated MIME subtype, "video/pointer." 


3.1. Registration of MIME media type video/pointer 
MIME media type name: video 
MIME subtype name: pointer 
Required parameters: None 
Optional parameters: None 


Encoding considerations: Pointer video can be transmitted with RTP 
as specified in this document. 


Security considerations: As described in this document. 
Interoperability considerations: None 
Published specification: this document. 


Applications which use this media type: Videoconferencing systems 
that transmit VUgraphs with a real-time pointer. 


Additional information: None 


Magic number(s): None 
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File extension(s): None 
Macintosh File Type Code(s): None 


Person & email address to contact for further information: 
M. Reha Civanlar 
e-mail: civanlar@research.att.com 


Intended usage: COMMON Author/Change controller: 
M. Reha Civanlar 
e-mail: civanlar@research.att.com 


4. Security Considerations 


RTP packets using the payload format defined in this specification 
are subject to the security considerations discussed in the RTP 
specification [1]. 


This payload type does not exhibit any significant non-uniformity in 
the receiver side computational complexity for packet processing to 
cause a potential denial-of-service threat. 
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7. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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